@SB-rohitdesai, it looks good! Do you plan to add any tests for this functionality though?

Actually everything is already covered to test async await functionality.

Pull Request Test Coverage Report for Build 9494945514

Details

• 7 of 7 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.05%) to 93.753%

Totals
Change from base Build 8325139558:	0.05%
Covered Lines:	1181
Relevant Lines:	1236

💛 - Coveralls

Pull Request Test Coverage Report for Build 9498353515

Details

• 7 of 7 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.05%) to 93.753%

Totals
Change from base Build 8325139558:	0.05%
Covered Lines:	1181
Relevant Lines:	1236

💛 - Coveralls

All those functions look synchronous to me 🤔 Why did you make them async? Can we get some benchmarking results on how it improves the derefencing speed?

Hi @rainum
As I updated all three files (In all three PR's) , we are able to reduce the time , if you want to see that , you can check the video which I attached to the ticket

All those functions look synchronous to me 🤔 Why did you make them async? Can we get some benchmarking results on how it improves the derefencing speed?

Hi @rainum As I updated all three files (In all three PR's) , we are able to reduce the time , if you want to see that , you can check the video which I attached to the ticket

Hi @rainum May be because of async its faster , But its giving response quickly than previous code

All those functions look synchronous to me 🤔 Why did you make them async? Can we get some benchmarking results on how it improves the derefencing speed?

Hi @rainum As I updated all three files (In all three PR's) , we are able to reduce the time , if you want to see that , you can check the video which I attached to the ticket

Hi @rainum May be because of async its faster , But its giving response quickly than previous code

We can't solve issues by using an "imperial" approach. There should be a reason for this. I don't want to have so kind of "magical" code in our codebase.

@brendarearden, do you have any thoughts regarding this one?

As far as I know making a function async shouldn't do anything to the execution time of the individual function and it might slightly increase the time because it has to create a promise in addition to running the function. So there is definitely a different underlying reason as to why this change optimized the execution time and I agree that we should have an answer to that. Is it possible that an await was not added somewhere so we just never wait for it to execute? I feel like the linter would've caught that.

I'd recommend using yalc or something similar to pull these changes into Prism, create a draft PR with the yalced version and add tests in the prism draft pr to demonstrate the optimization if you are not able to add test directly in here.